AWS Client VPN 構築で考えるべきだったこと(備忘録)

もきゅりん

2020.05.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

おはようございます、もきゅりんです。

昨今の状況もあって、ここしばらく AWS Client VPN を触れていました。

その中で見えてきた段取りというか、準備について個人的な備忘録的に整理しておこうと思った次第です。

実際の構築や設定についてはこの稿では触れません。

大きな段取りとしては下記の通りです。

どのようなシナリオを想定しているか
ネットワーク設計
認証・認可をどうするか
モニタリングをどうするか

注

本稿で記載されているクォータなどは既に更新されています！

最新情報を必ず確認の上、利用、設計するようにしましょう。

AWS クライアント VPN クォータ - AWS クライアント VPN

1 どのようなシナリオを想定しているか

シナリオと例にもあるように、まずはどのような用途となるかを明確にする必要があります。

それによって、2 ネットワーク設計 につながることになります。

1.1 VPC へのアクセス

クライアントに単一の VPC 内のリソースへのアクセスのみを許可する必要がある場合です。

access2vpc

参考:

[AWS Client VPN] カスタムDNSサーバを使用する

こちらのブログでは、カスタムDNSサーバを設定して VPCエンドポイントを利用しています。

1.2 VPCピアリング先のアクセス

クライアントにターゲット VPC およびそれとピア接続されている他の VPC 内のリソースへのアクセスを許可する必要がある場合です。

access2vpc-peering

参考:

Simple ADとAWS Client VPNを使ってピアリング先VPCのEC2にSSH接続してみた

1.3 オンプレミスのネットワークへのアクセス

クライアントにオンプレミスネットワーク内のリソースへのアクセスを許可する必要がある場合です。

Site-to-Siteが描かれていますが、DXなども想定されます。

access2onpre

1.4 インターネットへのアクセス

インターネットへのアクセスを許可する必要がある場合です。

access2internet

インターネットのアクセスには選択がいくつかありますが、社内のセキュリティポリシーによって対応が異なってくるかと思います。

社内のproxyなどを通すか
クライアントVPNのセキュリティグループで制御するか
スプリットトンネルで問題ないか

スプリットトンネルがどのようなものかは、下記の記事が分かりやすかったです。

AWS ClientVPN接続時にAWS VPCを介さずインターネット・オンプレミスネットワークに接続する方法

1.5 VPC 内の特定のリソースへのアクセス

1.1 VPC へのアクセスの制限版となります。

クライアント VPNが関連付けられているサブネットのENIにセキュリティグループを追加、削除することで制御することが可能です。

他のリソースに影響が生じないように、クライアント VPNのセキュリティグループは独立して作成するのが推奨です。

1.6 想定される接続ユーザ数

AWS アカウントはクライアント VPN エンドポイントに関して下記のようにAWS Client VPN のクォータがあります。

特に注意すべきは、同時クライアント接続数:2000 かと思います。

2 ネットワーク設計

クライアント VPN の制約事項および AWS Client VPN のクォータとを確認しながら設計します。

抜粋ですが下記のような仕様があります。

・クライアント CIDR 範囲は、ブロックサイズが /22 以上、/12 以下でなければなりません。
・クライアント CIDR 範囲は、関連付けられたサブネットが配置されている VPC のローカル CIDR、またはクライアント VPN エンドポイントのルートテーブルに手動で追加されたルートと重複することはできません。
・クライアント VPN エンドポイントは、クライアント VPN エンドポイントに関連付けるサブネットを含む VPC と同じアカウントに属している必要があります。
・サブネットには、少なくとも /27 ビットマスク (10.0.0.0/27 など) を持つ CIDR ブロックが必要です。サブネットには最低 8 個の利用可能な IP アドレスも必要です。
・複数のサブネットをクライアント VPN エンドポイントに関連付ける場合、各サブネットは異なるアベイラビリティーゾーンに存在する必要があります。アベイラビリティーゾーンの冗長性を提供するために、少なくとも 2 つのサブネットを関連付けることをお勧めです。

クライアントVPNの CIDR は既存で利用している、または今後利用されそうな CIDR を避けるのが無難かと思います。

また、後から何か変更があってもルーティングを自由に設定できるため、可能ならクライアント VPN用に関連付けるサブネットを2つ作るのがベターかと思います。

3 認証・認可をどうするか

以下 3点を決める必要があります。

Active Directory 認証と相互認証の一方または両方か
多要素認証 (MFA) を設定するかどうか
対象リソースのアクセス許可を特定のクライアントだけに与えるかすべてのクライアントか

3.1 Active Directory 認証

クライアント VPN は、Active Directory 認証と相互認証の一方または両方の認証方法を使用することができます。

Active Directory 認証は AWS Directory Service の Simple AD, AWS Managed Microsoft AD, AD Connector のいずれかと統合することで実現します。

Active Directory がどのようなもので、どう選択するかは、弊社ブログを参照したいと思います。

社内勉強会で AWSエンジニアのためのActive Directory入門という発表をしました

下記ブログでは、WorkSpaces が本筋なのですが、Active Directory の説明も捉えやすいと思いました。

AWS再入門ブログリレー Amazon WorkSpaces 編

以下抜粋です。

・ Simple Active Directory (以下 Simple AD) - WorkSpaces を使用するための必要最低限のディレクトリサービス、かつ、仮想デスクトップ OS に Windows のみ使用する場合
・ Directory Service for Microsoft Active Directory (以下 Microsoft AD) - 既存の Active Directory との信頼関係や多要素認証など、Simple AD では対応できない機能を使う可能性が残されている場合
・ Active Directory Connector (以下 AD Connector) - オンプレミス環境または Amazon EC2 上に構築された Active Directory ドメインコントローラを使って認証する場合

AWS Directory Service の Simple AD, AWS Managed Microsoft AD, AD Connector にはそれぞれ組織の大きさに応じてサイズがあるため、想定されるユーザー数を考慮して決める必要があります。

3.2 相互認証

相互認証がどのようなものかは、下記ブログが非常に参考になるかと思います。

SSLを改めて理解してから AWS Client VPN に挑む

相互認証では、付随する点として、証明書の運用管理をどうするか が生じます。

どこで誰が証明書を発行するか
(OPEN VPN easyrsa3を使った場合)期限はデフォルト2.2年で良いか
ユーザごとに証明書を作成するかどうか
クライアント証明書失効リストを作成するかどうか

なお、クライアント証明書の認証機関 (発行者) がサーバー証明書の認証機関 (発行者) と異なる場合にのみ、クライアント証明書を ACM にアップロードする必要があります。

3.3 多要素認証 (MFA) を設定するかどうか

クライアント VPN は、AWS Managed Microsoft AD または AD Connector で有効になっている場合、多要素認証 (MFA) をサポートしています。

こちらの設定については、弊社市田の怒涛の3連撃 MFAブログをご確認頂ければと思います。

3.4 対象リソースのアクセス許可を特定のクライアントだけに与えるかすべてか

クライアント VPN の設定で指定したネットワークにすべてのクライアントにアクセス許可を与えるか、または特定の Active Directory グループを指定することができます。

下記コマンドで、アクセス許可の対象とする Active Directory グループのセキュリティ識別子 (SID) を取得して設定します。

Get-ADGroup -Filter 'Name -eq "<Name of the AD Group>"'

4 モニタリングをどうするか

クライアント VPNを作成する前に、ロググループを作成しておく必要があります。

ログストリームに発行される connection-attempt のログ内容です。

common-name や device-ip でどのクライアントにおける接続ステータスかが判ります。

{
    "connection-log-type": "connection-attempt",
    "connection-attempt-status": "successful",
    "connection-attempt-failure-reason": "NA",
    "connection-id": "cvpn-connection-05d01d04f632a505d",
    "client-vpn-endpoint-id": "cvpn-endpoint-0459d3efd5c89b414",
    "transport-protocol": "udp",
    "connection-start-time": "2020-05-15 03:07:41",
    "connection-last-update-time": "2020-05-15 03:07:41",
    "client-ip": "172.17.8.2",
    "common-name": "client-5-0X.domain.tld",
    "username": "ad_connector",
    "device-type": "mac",
    "device-ip": "XXX.XXX.XXX.XXX",
    "port": "52059",
    "ingress-bytes": "0",
    "egress-bytes": "0",
    "ingress-packets": "0",
    "egress-packets": "0",
    "connection-end-time": "NA"

同 connection-id の接続終了時の connection-reset のログ内容です。

{
    "connection-log-type": "connection-reset",
    "connection-attempt-status": "NA",
    "connection-attempt-failure-reason": "NA",
    "connection-id": "cvpn-connection-05d01d04f632a505d",
    "client-vpn-endpoint-id": "cvpn-endpoint-0459d3efd5c89b414",
    "transport-protocol": "udp",
    "connection-start-time": "2020-05-15 03:07:41",
    "connection-last-update-time": "2020-05-15 03:09:18",
    "client-ip": "172.17.8.2",
    "common-name": "client-5-0X.domain.tld",
    "username": "ad_connector",
    "device-type": "mac",
    "device-ip": "XXX.XXX.XXX.XXX",
    "port": "52059",
    "ingress-bytes": "34924",
    "egress-bytes": "5370",
    "ingress-packets": "349",
    "egress-packets": "65",
    "connection-end-time": "2020-05-15 03:09:18",
    "connection-reset-status": "NA"
}

また、CloudWatch メトリクスからアラート設定するかどうか決める必要があります。

取得されるメトリクスはこちらに記載されています。